IaC是甚麼？

基礎設施即代碼（IaC，Infrastructure as Code），是透過程式碼，或是一組描述性的語言，來去定義以及管理基礎設施與系統設定，基礎設施包含但不限於網路、虛擬機、儲存空間、硬體資源、系統設定等等。IaC的出現解決了許多現實世界中會遇到的問題，包含了配置漂移、手動操作的低效率、環境設定可見性低，以及開發以及資訊部門溝通隔閡，這些都是可以透過IaC來解決的問題。

IaC 有許多的好處，可以提升效率部屬和管理，避免飄移配置的問題，設定透明化，可以進一步做設定的版控。使用 IaC 的優勢整理：

1. 自動化：IaC允許您自動化基礎設施的建立、配置和管理。這意味著您可以使用程式碼來執行重複性任務，減少了手動錯誤的風險，提高了效率。
2. 可重現性：通過IaC，您可以確保每次部署都是一致的。您可以複製和重現整個基礎設施，確保環境的一致性，減少了配置差異和問題的可能性。
3. 安全性：IaC可以幫助您實現安全的基礎設施實踐。您可以在程式碼中包含安全性最佳實踐，並自動應用安全更新和修補程序，以減少安全漏洞的風險。
4. 可版本控制：IaC程式碼可以集成到版本控制系統中，如Git，這使得基礎設施的變更可以被追蹤、管理和回滾。這有助於團隊協作和緊急情況下的快速修復。
5. 彈性和擴展性：使用IaC，您可以輕鬆地擴展或縮減基礎設施，以應對應用程序需求的變化。只需編寫新的程式碼或調整現有程式碼，而不需要手動干預。
6. 文檔化：IaC程式碼通常具有良好的文檔，這有助於團隊成員理解和管理基礎設施的配置。它也有助於新成員迅速上手，並提供了基礎設施的易於理解的視覺表示。
7. 成本控制：IaC可以幫助您更有效地管理基礎設施成本。您可以輕鬆地調整配置以符合需求，並在不需要的部分自動關閉資源，以節省費用。

環境配置與系統管理

IaC 工具根據目的類型，IaC 通常有分成配置（或部署）（Provisioning）與系統管理（Configuration Management）兩大類。配置通常是指創建基礎架構並將其提供給最終使用者的過程，例如透過CloudFormation 在 AWS 上建立一台新的 EC2 計算資源。此類型常見的工具有 Terraform、AWS CloudFormation 和 Pulumi。

而系統管理則是針對已部署或配置好的的基礎設施資源進行管理設定的過程。例如，利用 Ansible 針對已啟動的遠端 EC2 伺服器進行安裝和配置數據庫或配置網路設定。此類型常見的工具有 Ansible、Chef 和 Puppet。

Hardening 安全強化

在資訊安全藍隊的領域中，"Hardening"（安全強化、加固、硬化）指的是加強計算機系統、網路、應用程式或設備的安全性，以降低受到攻擊的風險。

這是一種預防性的安全措施，目的在減少攻擊者可能利用的弱點和漏洞，使系統更加健壯和抵抗攻擊。其實就是你可以做哪些事情，來做好安全設定 ，加固安全防護。

Hardening 可以涉及多個層面跟領域，今天範例會使用 IaC 針對作業系統來進行安全強化。

IaC 工具：Ansible

IaC 的工具我們會使用 Ansible，所以就要來介紹跟操作一下 Ansible。

Ad-hoc 與 Playbook 方式

安裝

sudo apt update
sudo apt install -y python3-pip
sudo pip3 install ansible==6.4.0 ansible-lint==6.8.1

確認 ansible 安裝正常

ansible -h

然後我們可以建立一個資產清單

cat > inventory.ini <<EOL

# HackerCat Inventory
[blueteam-db]
192.168.101.141

EOL

將遠端主機的 fingerprint 先記錄在 known_hosts

（補充一下，Ansible 是透過SSH連線去執行，所以我這邊範例，安裝 Ansible 的主機是有 SSH Private Key，遠端主機是有配置好 SSH Public Key 的）

ssh-keyscan -t rsa 192.168.101.141 >> ~/.ssh/known_hosts

Ansible有兩種方式可以執行命令，分別是：

• Ad hoc Command
• Playbook

ad-doc 通常拿來做測試或是完成簡單的任務而已；playbook 比較適合拿來作為正式使用和完成比較多項的指令任務。

Ad hoc Command 方式

舉例來說，我們先用 Ping 來確認主機存活、Ansible 可以正常運作

ansible -i inventory.ini all -m ping

我們來執行顯示 bash 的版本

ansible -i inventory.ini all -m command -a "bash --version"

使用 playbook 的方式

cat > playbook.yml <<EOL
---
- name: Check Bash Version on all Hosts
  hosts: all
  gather_facts: yes
  tasks:
    - name: Get Bash Version
      command: bash --version
      register: bash_version_output

    - name: Display Bash Version
      debug:
        var: bash_version_output.stdout_lines
EOL

ansible-playbook -i inventory.ini playbook.yml

Ansible Modules

接著來提一下模組（Modules）

Ansible 當中有提供許多的 Modules 可以使用。Modules 就有點像是 ansible 的專用指令或是涵式庫，我們可以在 ansible 當中使用模組，執行特定的操作。modules 可以利用 ad-hoc 調用，在 playbook 中也可以使用。

簡單舉例大家就明白。以下調用的 moudle 是 copy，這個模組就是複製檔案用的。

參數用來需要參考官方對於該模組的說明。這邊的用法是將執行 Ansible 的主機上的 /etc/hosts 給複製到目標主機的 /tmp/hosts。

ansible -i inventory.ini all -m copy -a "src=/etc/hosts dest=/tmp/hosts"

ansible 有提供許多常用的 module，那如果想要自己寫 module 也是可以自訂義。

Ansible Roles

接著要介紹一個比 module 更強大便利的東西，叫做 Roles。Role 是能夠根據層次結構去包裝和組織文件、變數、任務與 Playobook 的方法。可以想成是 role 就是一個目錄，這個目錄底下的各種內容可以被方便的被 include 去使用，也可以更好的被重複使用跟維護。

Role directory structure

roles/
    common/               # this hierarchy represents a "role"
        tasks/            #
            main.yml      #  <-- tasks file can include smaller files if warranted
        handlers/         #
            main.yml      #  <-- handlers file
        templates/        #  <-- files for use with the template resource
            ntp.conf.j2   #  <------- templates end in .j2
        files/            #
            bar.txt       #  <-- files for use with the copy resource
            foo.sh        #  <-- script files for use with the script resource
        vars/             #
            main.yml      #  <-- variables associated with this role
        defaults/         #
            main.yml      #  <-- default lower priority variables for this role
        meta/             #
            main.yml      #  <-- role dependencies
        library/          # roles can also include custom modules
        module_utils/     # roles can also include custom module_utils
        lookup_plugins/   # or other types of plugins, like lookup in this case

    webtier/              # same kind of structure as "common" was above, done for the webtier role
    monitoring/           # ""
    fooapp/               # ""

https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_reuse_roles.html

如果我們要去下載和管理 Ansible 的 Roles 可以利用 ansible-galaxy。

https://docs.ansible.com/ansible/latest/cli/ansible-galaxy.html

利用 Role 來進行 Linux 的安全設定

講了這麼多漸漸要進入我們 hardening 的主題 XD

在 ansible 當中有個相當方便的 hardening 的 role

叫做 devsec.hardening

https://github.com/dev-sec/ansible-collection-hardening

我們可以透過 ansible-galaxy 來安裝我們的 devsec.hardening

ansible-galaxy install dev-sec.os-hardening

我們可以編寫我們的 playbook 腳本，內容使用 dev-sec.os-hardening，去強化我們的主機安全。

這個腳本執行之後它就會自動會去進行 OS hardening 的工作，這就是一種透過 IaC 來達成安全強化的實作方法。

cat > ansible-hardening.yml <<EOL
---
- name: Playbook to harden Ubuntu OS.
  hosts: all
  remote_user: wazuh
  become: yes
  become_user: root

  roles:
    - dev-sec.os-hardening

EOL

ansible-playbook -i inventory.ini ansible-hardening.yml --ask-become-pass

（因為設定可能需要 Sudo，也就是 Root 權限，我這邊使用 ask-become-pass 的參數。實際上要達成提權的手法有很多種方式，例如設定密碼在 inventory.ini，設定目標主機的NOPASSWD，能成功取得權限的方式很多種）

當然這個腳本在生產環境上面是不能亂跑的，萬一自動設定完成後，影響到生產環境的服務可就糟糕了。不過可以在初始化設定完成之後先利用 IaC 強化，然後在逐項修正了解哪些項目可能是需要調整的。

但這樣下次再執行該腳本，又會覆蓋掉自己手動調整的設定。所以可以的話，更好的情況是了解 os_hardening 到底有做了那些設定，自己去修改裡面的內容。

那可以參考官方的文件

https://github.com/dev-sec/ansible-collection-hardening/tree/master/roles/os_hardening

也可以直接運行 role 就好，看結果大概就知道有做了哪些操作。

官方內容其實有提到他是根據 DevSec Linux Baseline

這個就是我們下一篇文章會介紹的內容了～

隨著 DevOps 逐漸成熟的發展，Ansible 應該是已經被許多組織所使用了，在網路上的教學與參考資源也已經相當豐富與完整。

所以我這篇文章主要是以簡易介紹基礎知識，以及達成 IaC 執行安全設定、安全防禦強化（Hardening）所需的內容為主。

這邊，貼兩個外部資源給大家參考：

《現代 IT 人一定要知道的 Ansible 自動化組態技巧》
https://chusiang.gitbooks.io/automate-with-ansible/content/

《ansible中文權威指南》
https://chusiang.github.io/ansible-docs-translate/index.html